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ABSTRACT 



A system and method are disclosed for authenticating users 
and services communicating over an insecure network. Each 
user and service has a pass-phrase used for authentication. 
However, the pass-phrases are not revealed during the 
authentication process as challenge-response techniques are 
used to keep the pass-phrase secret In addition, the users 
and services do not need to know nor do they learn each 
other's pass-phrases making the process useful in a distrib- 
uted environment Pass-phrases are known by an authenti- 
cation entity with which the service communicates to 
authenticate both users and services. Users may have iden- 
tities in and services may support a number of realms, each 
of which may be viewed as large collection of users (e.g., 
CompuServe.com). Users choose the realm in which they 
would like to be authenticated. In one embodiment of the 
present invention, the system and method are adapted for use 
with the HyperText Transfer Protocol of the World Wide 
Web so that secure transactions may be accomplished 
between users and services communicating via the Internet 

26 Claims, 3 Drawing Sheets 
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SYSTEM FOR REMOTE PASS-PHRASE 
AUTHENTICATION 

BACKGROUND OF THE INVENTION 

1. Held of the Invention 

The present invention relates to authentication of com- 
puter users and services in distributed environments. 
Particularly, the present invention relates to a Remote Pass- 
phrase Authentication scheme that provides a way to authen- 
ticate users and services using a pass-phrase over a computer 
network without revealing the pass-phrase. 

2. Description of the Related Art 

The importance of secure communication is increasing as 
world-wide networks such as the Interact and the World 
Wide Web (WWW) portion of the Internet expand. As global 
networks expand through the interconnection of existing 
networks, users may gain access to an unprecedented amber 
of services. The services, each of which may be maintained 
by a different provider, give users access to academic, 
business, consumer, government, etc information. Service 
providers are now able to make their services available to an 
ever-expanding user base. 

The ease with which services and users are able to find 
each other and the convenience associated with on-line 
transactions is leading to an increase in the number of 
remote business and related transactions. However, users 
and services are not always certain who or what is at the 
other end of a transaction. Therefore, before they engage in 
business and other transactions, users and services want and 
need reassurance that each entity with whom they commu- 
nicate is who or what it purports to be. For example, users 
will not be willing to make on-line purchases that require 
them to reveal their credit card numbers unless they are 
confident that the service with which they are communicat- 
ing is in fact the service they wanted to access. Commercial 
and other private entities who provide on-line services may 
be more reluctant than individuals to conduct business 
on-line unless they arc confident the communication is with 
the desired individual or service. 

Both users and services need reassurance that neither will 
compromise the integrity of the other nor mat confidential 
in formation will be revealed unintentionally to third parties 
while communications are occurring. Security in a global 
network, however, may be difficult to achieve far several 
reasons. First, the connections between remote users and 
services are dynamic. With the use of portable devices, users 
may change their remote physical locations frequently. The 
individual networks that comprise the global networks have 
many entry and exit points. Also, packet switching tech- 
niques used in global networks result in numerous dynamic 
paths that are established between particq)ating entities in 
order to achieve reliable communication between two par- 
ties. Finally, communication is often accomplished via 
inherently insecure facilities such as the public telephone 
network and many private communication facilities. Secure 
communication is difficult to achieve in such distributed 
environments because security breaches may occur at the 
remote user's site, at the service computer site, or along the 
communication link. Consequently, reliable two-way 
authentication of users and the services is essential for 
achieving security in a distributed environment. 

Two-way authentication schemes generally involve hand- 
shaking techniques so that each party may verify he or she 
is in communication with the desired party regardless of 
each party's location or the types of devices in use. The 
problem to be solved is one in which a user communicates 



1,361 

2 

with a service mat wishes to learn and authenticate the user's 
identity and vice versa. To clarify the problem, there are 
three aspects of network security that may be distinguished: 
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the way in which a user or service is 




referenced. 


Authentication: 


the way in which a user may prove his or her 




identify 


Autborizatioa- 


a method for (le'^ mining what a given user 




may do. The same aspects apply to services 




as well as users. 



Identification 

A user's identity consists of a user name and a realm 

is name. A realm is a universe of identities. CompuServe 
Information Service (OS) user IDs and America Online 
(AOL) screen names are two examples of realms. The 
combination of user name and realm—- typically shown as 
name@realm — identifies a user. Any given service recog- 

„ nizes some particular set of identities. A realm does not have 
to be large, though, either in number of users or size of 
service. For example, a single WWW server may have its 
own realm of users. 

Often, a service recognizes only one realm: CIS recog- 
nizes only identities within the CIS realm and AOL recog- 

23 nizes only identities within the AOL realm- But, one can 
imagine a service that has agreements with bom CIS and 
AOL. The service gives the user a choice of realms — 
"Please supply a CIS or AOL identity, and prove it" — and 
the user chooses a realm in which he or she has an identity. 

30 Identification, thus, provides the ability to identify, or to 
refer to. a user. 
Authentication 

Authentication provides the ability to prove identity. 

35 When asking to do something for which a user's identity 
matters, the user may be asked for his or her identity — a user 
name and realm — and the service requires the user to prove 
that he is who he says he is. To accomplish this, most 
services use a secret called a pass-phrase, although it is not 
necessarily derived from text Such a secret is sometimes 
called a secret key, but it is not necessarily used for encryp- 
tion. In this context, the fundamental problem to be solved 
is: How can a user prove his pass-phrase without revealing 
the pass-phrase in the process? 

45 Authorization 

Authorization refers to the process of determining 
whether a given user is allowed to do something. For 
example, may he post a message? May he use a surcharged 
service? It is important to realize that authentication and 

50 authorization are distinct processes— one related to proving 
an identity and the other related to the properties of an 
identity. The present invention is not related to 
authorization, but it is designed to co-exist with authoriza- 
tion mechanisms. 

55 Pass-phrase 

A service that wishes to authenticate a user requires the 
user to identify himself or herself and to prove that he or she 
knows the pass-phrase. Generally, the service prompts the 
user for the pass-phrase. However, transmitting the plain text 

60 pass-phrases through a network comprises security because 
an eavesdropper may learn the pass-phrase as it travels 
through the network. X.25 networks have been 
compromised, and LANs, modem pools, and 'The Internet" 
likewise are not suitable for plain text pass-phrases due to 

65 the eavesdropper problem. Prompting for the pass-phrase, 
while sufficient in the past, no longer works for extensive 
world-wide networks. 
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Pass-phrase Encryption 

Encryption of the pass-phrase provides additional security 
and addresses the eavesdropper problem* Using encryption, 
the user encrypts the pass-phrase, sends the result to the 
service which then decrypts it. Some techniques are based 
on a one-time key that prevents an eavesdropper from 
decrypting the pass-phrase. 

There are. however, problems with this technique as well 
Somebody else — a spoofer — may pretend to be the service. 
The spoofer decrypts the result, learns the pass-phrase, and 
gains the ability to masquerade as the user. Some people 
have spoofed services by getting users to dial into the 
spooler's computer. The spooler advertises a dial up number 
for the service that is claimed to have been omitted from the 
directory of service numbers. The spoofer may entice people 
to try the '"unlisted" number by claiming it is much faster 
than the listed numbers. Therefore, there is a need for a 
mechanism that will not reveal the pass-phrase to anyone, 
even if the user is interacting with a spooler. 

Challenge-response Techniques 

Challenge-response techniques involve a series of 
exchanges between a user and a service. The service sends 
the user a challenge, which is a random number, and the user 
applies a one-way function to the number to calculate a 
result that depends on the challenge and the user's pass- 
phrase. The user sends the result to the service which 
performs the same calculation and compares the result to the 
result sent by the user. Done correctly, this technique reveals 
no information to eavesdroppers, nor does it allow a spoofer 
to acquire the pass-phrase— -if a spoofer pretends to be the 
service, he learns the result only for a particular challenge — 
which is of no value. Although such a technique works, it 
does not solve the problem completely. The service must 
know the pass-phrase in order to reproduce the user's 
calculation and verify the user's response to the service's 
challenge. 

The service may not know the user's pass-phrase for 
several reasons. A set of services may share a set of users* 
identities. For example, a collection of Web servers, scat- 
tered throughout the world, may be part of a *Total Infor- 
mation Service (TIS). M A user requesting access to ITS may 
use her TIS user name and pass-phrase to identify herself to 
any US service. In accordance with one implementation, 
each physical server may have a copy of all pass-phrases or 
access to a master database containing all pass-phrases. This 
solution may not, however, work under all scenarios — 
especially if some are third-party servers, not directly under 
the control of the imaginary ITS. Or consider a service that 
accepts identities in multiple realms — for example, a service 
that has agreements with both CIS and AOL. The service 
gives the user a choice of realms — 'Please supply a CIS or 
AOL identity, and prove if — and the user chooses a realm 
in which he has an identity. It is unlikely that CIS and AOL 
will entrust a copy of their pass-phrase databases to a 
third-party service, or to each other. If the service docs not 
how the user's pass-phrase, then the user cannot prove to the 
service that he knows it 

One technique to address this problem is to have the 
service prompt the user for her pass-phase. For example, a 
WWW service may display a Hyper-Text Markup Language 
(HTML) form with two boxes— one that asks for the user far 
her user name and one that asks her for her pass-phrase. A 
protocol such as SSL or SHTTP may be used so an eaves- 
dropper cannot see it. When the service receives the user's 
reply, the service may use a challenge-response technique to 
verify the pass-phrase with a server that knows the pass- 
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phrases. But, there is a drawback to this technique. It is 
important to teach a user not to type his or her pass-phrase 
just because somebody asks for it. This technique is com- 
monly used for cracking others' accounts. Teaching users to 
provide their pass-phrases in a HTML form is not a desirable 
solution because the pass-phrase is revealed, which is pre- 
cisely what should be avoided, especially if the service is a 
spoofer. 

The pass-phrase database server also has some undesir- 

> able side effects. Using this scheme, me service 
for a copy of her pass-phase. Now, an ordinary challenge- 
response technique may be used. However, there is a need to 
get the pass-phrase from that database to the service, safely. 
If the service can look up the pass-phrase, then anybody else 

5 may do the same. Even worse, the entire pass-phrase data- 
base may be accessed so that pass-phrases for many users 
may be obtained. 

Current authentication mechanisms are inadequate for the 
distributed systems, services, and users that comprise 

3 today's world-wide networks such as the WWW/Internet 
Users and services need a way to reliably authenticate one 
another that also meets specific design criteria. Users and 
services also have a need for a mechanism that is adaptable 
to the many communication protocols used throughout 

5 world-wide networks and that is straightforward for users to 
use. These criteria and others are met with the present 
invention. 

SUMMARY OF THE INVENTION 

0 The present invention— Remote Passphrase Authentica- 
tion (RPA) — provides a way to authenticate a user to a 
service by using a pass-phrase over an insecure network, 
without revealing the pass-phrase to eavesdroppers. RPA is 
designed so that the service need not know and does not 

5 learn the user's pass-phrase. Consequently. RPA is useful in 
distributed environments where it would be difficult or 
inappropriate to trust a service with a pass-phrase database 
or to allow the service to learn enough to masquerade as the 
user in a future authentication attempt In one embodiment 

0 of the present invention, users and services on the WWW/ 
Internet use the mechanism of the present invention to 
authenticate one another. 

Using the present invention, a service may authenticate a 

3 user and a user may authenticate a service. Authentication is 
accomplished using pass-phrases (which may be derived 
from textual phrases). The goal is to prove to the service that 
the user knows the pass-phrase, and vice versa. Techniques 
are employed to minimize the possibility that the pass- 

0 phrase is revealed to an eavesdropper or a spoofer. 

Using RPA, a "user" communicates with a "service" that 
wishes to learn and authenticate the user's identity. An 
authentication "deity" knows the users' and services 1 pass- 
phrases. The service communicates with the authentication 

5 deity during the authentication process. If the service knows 
the pass-phrases, then it acts as its own deity, simplifying the 
implementation but. otherwise having no effect on the 
mechanism 

Identities for users exist in a 'realm" which may be 
o viewed as a relatively large collection of users — such as 
compuserve.com or aol.com — but it may well consist of a 
small set of users (e.g.. user names and pass-phrases asso- 
ciated with an individual Web server.) The service may 
specify a set of realms so that it may recognize an identity 
,5 in any of the realms in which it participates. 

This authentication mechanism of the present invention 
consists of three related processes: authentication. 
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reauthentication, and reauthentication cheating. Autheatica- The authentication deity generates and sends to the ser- 

tion is the fundamental process by which a user and a service vice authentication proofs for the service and the user, 

mutually authenticate one another within one of a set of The service verifies its authentication proof and for- 

realms, without revealing their pass-phrases to one another. wards the other authentication proof to the user. The 

Reauthentication is a process by which a user and service, 5 user then verifies its authentication proof, 
having recently authenticated one another, may again 

authenticate one another. They may, of course, simply repeat BRIEF DESCRIPTION OF THE DRAWINGS) 
the authentication process, but that requires interaction with 

an authentication deity. The reauthentication process is FIG. 1 is a system block diagram for a preferred embodi- 

f aster, requiring no communication with a third party. Reau- ^ roent of the present invention; 

thentication is useful when multiple connections between fig. % illustrates an authentication protocol for a pre- 

the user and service are establishe d, whe ther sequential as in f erred embodiment of the present invention; and 

Hyper-Text Transfer Protocol (HTTP) or simultaneous. m 3 mustrates a ^authentication protocol for a pre- 

Preferably, each connection is authenticated, but the reau- ferxed embodiment of the present invention, 

thentication process provides a shortcut ^ 

Authentication DETAILED DESCRIPTION OF THE 

Three parties or entities participate in the authentication PREFERRED EMBODIMENT(S) 
process: 

me user Referring to FIG. 1, a system block diagram for a pre 



ferred embodiment of the present invention is shown. Three 
entities or parties participate in the authentication process of 



the service; and 20 

toe authentication deity. te^cnt invention! " 

Each user has a user name and a pass-phrase in some 

realm of interest Similarly, each service has a name and a uscr 

pass-phrase in that realm. The pass-phrase is not text but is me service 20, 22; and 

instead a 128-bit (16-octet) string of bits. However, it is 25 the authentication deity 16, lfl 

often useful to use pass-phrases in the conventional, textual The entities communicate with one another via a global 

sense, so a procedure is defined for convening a textual computer network 10 such as the Internet In an alternative 

phrase to the 128-bit value used by the authentication emboaiment, the three participating entities may be part of 

mechanism of the present invention. a small, domestic computer network. The computer network 

The service may specify a list of realms and the user may 30 10, which uses a message passing scheme for communica- 

choose one in which he has an identity. For example, a CIS tion between entities, may be comprised of network node 

user may choose to be authenticated in the CIS realm. Thus, computers 24 that route messages through the network to the 

a service is not restricted to authenticating identities in a communicating entities 12. 14, 16, 18, 20. 22. The network 

single realm. The service possesses a name and pass-phrase node computers may rely on servers 26 mat access databases 

in all realms it specifies. 35 28 to obtain routing and other information needed to facili- 

Each realm has an authentication deity that knows the tate network traffic, 

names and pass-phrases of its members. The service locates To communicate with one another, each entity establishes 

an authentication deity for each realm. If the service knows a connection 40, 42, 44, 46, 48, 50 to the network 10. 

the user's pass-phrase, it performs the role of the authenti- Network connection options for the entities are varied and 

cation deity itself, but this does not affect the mechanism. 40 may include a local area network (LAN) or the public 

The primary steps for a preferred embodiment of the present telephone network via a modem or a dedicated line such as 

invention are as follows: a JC25 link or a satellite or fiber optic link. Using addressing 

The service supplies a sequence of realms, with the information provided by the users 12, 14 and services 20, 22, 

service's name in each realm, to the user. the network facilitates communications so that any one 

The user chooses a realm The chosen realm and the user's « entity may communicate, either in real time or by leaving 

name in that realm are communicated to the service. messages, with another entity on the network. For example. 

The service and user exchange random challenges. User 1 may comnmm^te with Service A 20 Service B 22, 

The user calculates a response and sends it to the service. « 2 (14). Service B 22 ^^—^^^^ 

_ r A 20 or with either User 12, 14. Although two users and two 

The service calculates a response. ^ scrvicc5 m & 0V/D far simplicity, in reality, millions of users 

The service sends a request to the authentication deity for and scrviccs ^ communicate with one another through the 

the realm in question. The request contains the realm computer network 10. 

name, the user's name, the service's name, the user's To usc each ^ 12 14 ^ assigned a user name and 

challenge, the service's challenge, the user's response, a p^p^e in somc realm of interest (e.g.. compuserve- 

and the service's response. 55 <com & aol.com). Similarly, each service 20, 22 has a name 

The deity uses the realm, service, and user name to look ^ a pass-phrase for the realms that it supports. The 

up the user's and service's pass-phrases. pass-phrase is not text, but is instead a 123-bit (16-octet) 

The deity uses the values in the request, plus the service's stdag of bits. However, it is often useful to use pass-phrases 

pass-phrase to verify the service's response. fa the conventional, textual sense, so a procedure is defined 

Having verified the requesting service's identity, the deity 60 for converting a textual phrase to the 128-bit value used by 

uses the values in the request plus the user's pass- the authentication mechanism of the present invention, 

phrase to verify the user 1 s response. A service may support multiple realms, each of which has 

Having verified both the user's and service's identity, the its own authentication deity 16, 18. By supporting multiple 
deity creates a random. 128-bit session key for use by realm* a service may be able to increase its user base by 
the user and service. They may use it for session 65 making itself available to users who have a user name/pass- 
encryption or for the reauthentication process described phrase in only one realm. User name/pas s-phrase and 
later. service/pass-phrase pairs used by each authentication deity 
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20. 30 that supports a particular realm may be stored in a 
database 30, 32 for retrieval during the authentication pro- 
cess. The authentication deity with which a service commu- 
nicates to complete the authentication process depends on 
the realms offered by the service and the realm selected by 
the user. The service then locates the authentication deity for 
the selected realm. If the service knows the user's pass- 
phrase, it performs the role of the authentication deity itself, 
but this does not affect the mechanism. 

The following values are involved in the authentication 
process of the present Invention. 



As: Authentication deity's re^xrasc to service; 

proves user's identity 
Air Authentication deity's rehouse to user, 

proves service's identity 
Cs: Challenge from service 
Cu: Challenge from user 
Kus: Session key tor user and service 
Kuss: Session key obscured so visible only to 
service 

Kusu: Session key obscured so visible only to 
user 

Nr. Realm name 
Ns: Service name 
Nu; User name 

Ps: Service's pass-phrase, a 128 bit value 
Pu: User's pass-phrase, a 128 bit value 
Us: Service's response to challenge (during 

authentication process, goes to 

authentication deity; during 

reauthentication, goes to user) 
Rix User's response to challenge (during 

authentication process, goes via service to 

authentication deity; during 

reau&entkation, goes to service) 
2z Padding consisting of 48 octets (384 bits) 

with all bits set to zero 
+: Ccncatentauon of octet strings 
ran Bitwise "Exclusive Or" 



20 



23 



30 



35 



Preferably, bit patterns for each value are specified so that 
different implementations may be supported. For example, 
one implementation may use ASCII, another EBCDIC, and 
another Unicode far the user name. Another implementation 
may convert the user name to lowercase and another to all 
caps. The different implementations produce different 
results for the same calculation so the authentication may 
tail. The details may be left to underlying protocol, but that 
makes the service-to-deity protocol dependent on the user- 
to-service protocol. Using such a scheme makes it difficult 
to provide a single deity for each realm. By specifying the 
bit patterns, any mixture of user-to-service and service-to- 
deity protocols may be used to operate on the same data. 

The following conventions facilitate the development of a 
single deity to support multiple realms. Preferably, text 
strings are represented in the Unicode character set in 
big-endian byte order, without a trailing null character. Each 
16-bit Unicode character may be stored in two octets, with 
its high-order 8 bits in the first octet The specification refers 
only to values used in the authentication calculations, not the 
underlying protocol. For example, a protocol may use ASCII 
for user names, if that character set is adequate. The ASCH 
characters may be converted to Unicode before using them 
in authentication calculations, but the protocol need not 
transmit Unicode characters. 

Names — Nr. Ns. Nu — are converted to lowercase Uni- 
code. 

Challenges — Cs, Cu — arc arbitrary strings of octets, not 
text. They may contain any bit patterns, including nulls, 
and are preferably, at least eight octets in length. 
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Pass-phrases — Ps, Pu — are 16-octet quantities that con- 
tain arbitrary bit patterns, including nulls. If the pass- 
phrase is based on a textual phrase, the textual phrase 
is converted to a 16-octet quantity by the following 
process: 

Convert the text string to a sequence of characters in 
either the Unicode or ISO 8859-1 character sets, as 
appropriate for the realm. 
Convert each character to its lowercase equivalent, or 
its uppercase equivalent or leave it alone, as appro- 
priate for the realm. 
Store the sequence of characters in an octet stream, 
with each Unicode character in two consecutive 
octets in big-endian order, or each ISO 8859-1 
character in one octet 
Take the MD5 digest of the resulting string of octets. 
The result is the 128-bit value to use in the authen- 
tication calculations. 
A realm specifies which of the preceding options — 
character set, case conversion, and hash function — it uses 
for the text-to- 128-bit value transformation. Preferably, the 
defaults are Unicode, convert to lowercase, and MD5. The 
user-service protocol may be designed to convey the appro- 
priate options for each realm from the service to the user, if 
other than the defaults are to be supported, to avoid requiring 
the (human) user to manually configure software. 

Referring to FIG. 2, the primary steps for a preferred 
embodiment of the present invention are shown. 
The authentication process begins when a user attempts to 

access a service 60. 
In response to the user's access attempt the service 
supplies a sequence of realms, with the service's name 
in each realm, to the user 62. A user may choose a realm 
in which he has an identity. For example, a CIS user 
may choose to be authenticated in the CIS realm while 
an AOL user may choose to be authenticated in the 
AOL realm, [fco@compuserve.com bar@aol.com may 
mean "Please identify yourself with a CIS user ID. If 
you don't have one, your AOL ID will do."] Preferably, 
the service indicates its realm preferences in most- 
preferred to least-preferred order. By specifying only 
one realm, the service requires identification in that 
realm. 

The user chooses a realm. Nr. and gives it and his name 
in mat realm, Nu, to the service 64. That in turn, 
determines Ns, the service's name in that realm. Note 
that a protocol may allow the service to include a null 
realm name, m M i! n g *TU accept you as an anonymous 
user if you wish." The user may make this choice by 
supplying a null name; then the process stops here, and 
no authentication is performed. 
The service transits a random challenge. Cs 66. The 
challenges are random values that make each authen- 
tication unique. 
The user sends a random challenge. Cu 68. 
The user calculates a response, Ru: 

Ru=MD5(Pu+Z+NiH-Ns+Nr+Cu-r€s+Pu) 
The response is sent to the service 70. Only the real user 
may generate the correct response because it depends 
on the user* s pass-phrase. Pu. Generally, user's pass- 
phrase may not be determined from a captured 
response because it's generated by a one-way func- 
tion (although there is the risk of a dictionary attack 
if Pu is based on a poorly chosen pass-phrase.) 
The service calculates a response. Rs: 

Rs=MD5(Ps+Z+Nu+Ns+Nr-r€u+Cs+Ru+Ps) 
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This response is not sent to the user. It may be seen by ally authenticate without talking to a deity. This technique is 

the user, but the user does not need it useful for protocols such as HTTP which involve a sequence 

The service sends a request to the authentication deity for of connections that are independently authenticated. It is 

the realm in question 72. The request contains the realm useful with parallel connections— for example, in a 

name, Nr (included so the same deity may serve more * scheme in which a user and service are connected and wish 

than one realm), the user's name, Nu, the service's 10 establish a second connection. 

name, Ns, the user's challenge, Cu, the service's To reaumenticate one another, the user and service prove 

challenge, Cs, the user's response, Ru, the service's to each other that they both possess a secret 128-bit key— the 

response, Rs session key. Kus, derived during the authentication process. 

The deity uses Nr.Ns, and Nu to look up the user's and 10 ™ c ; reauthenticatJon process is essentially an odlnary 

service's pass-phrases. challenge-response mechanism in which the session key is 

The deity uses the values in the request, plus the service's US *** aS a ^ >aSS "^ hr ^ Se " t „ _ ^ 

pass-phrase, Ps, to verify Rs. If it is incorrect, the deity ^ scrvice *»* a challenge, Cs, to the user 80. 

returns a negative response as this request apparently The user sends a challenge. Cu, to the service 82. 

did not come from a legitimate service 74, The user calculates Ru: 

Having verified the requesting service's identity, the deity Ru=MD5(Kus+Z+Ns+Nu+Nr4Cs+Ca+Kus) 

uses the values in the request, plus the user's pass- The response is sent to the service 84. 

phrase. Pu. to verify Ru. If it is incorrect, the deity The service verifies the result Ru. If correct it calculates 

returns a failure response to the service as the user does ^ Rs: 

not know the correct pass-phrase 74. Rs=MD5(Kus+Z+Nu+Ns+Nr-fCu+Cs+Kus) 

Having verified both the user's and service's identity, the The response is sent to the user 86. (Both responses 

deity creates a random, 12M>it session key. Kus, for involve the same set of values, but they are used in 

use by the user and service. They may use it for session a different order, so the responses are different) 

encryption. In addition, it may be used in the reauthen- 25 The user verifies the result 

tication process described later. Reauthentication Cheating 

The deity generates two obscured copies of the session *> som * protocols, it may be more efficient to shortcut the 

key . reauthentication process by cheating. One technique is to 

Kuss=Kus xor MD5(Ps+Z+Ns+Nu+NrK:s+CiHPs) * e Aumorization header to be replayed ("P 

Kusu=Kus xor MD5(Pu+Z+Ns+Nu+Nr4Cs-»Cu+Pu) 30 example, to embed a challenge-response technique in HTTP, 

The obscuring masks resemble Ru and Rs. but differ so *w<> HTIP transactions may be used for authentication 

an eavesdropper may not recover Kus. a challenge may not be sent and a response received 

The deity generates a pair of authentication -proofs": in K ~ ^VT^ "T^JtSilZ Zl™ 

Au^SCPu+Z+Ns^u+Nr+Kusu^s^+Kus+Pu) ^enged without MD ^ h ^^^^^ 

^ lT ,v T lir ,„ ,„ ,„ , Wl tication may be accomplished in one HTTP transaction. A 

A^MD5(P S+ Z + Ns + Na + Nr + K U ss-K: S+ Cu- t -Ku S -f-M + 35 J^,, used to accomplish authen- 

HereVisthe message transmitted from the deity to ti<^o» by trea^fte Uniform Resource Identifier (URI) as 

the service. It is included in the calculation to authen- a aauenge as roiiows. 

ticate the response to the service. The first time, the user andsemce perform the authen- 

The deity sends the four values Kuss, Kusu. As, and Au <° J lc8tlon ^ " deSCn ^,^° Ve . . „ . 

.„ . The user and service remember the session key (Kus) and 

to the service. chaUenges (Cu and Cs). 

The service extract, its copy of the session key from Kusa he M 

by calculating the obscuring mask value and XORmg. Authori2atic | header containing a response calculated 

(The service may determine the user's key-obscuring 6 r 

1 rtfV \ The method and URI are canonicalized by taking the 

re D 8 e t t big-endian Unicode representation and converting all char- 

The service verifies As by performing the same calcula- actcrs t0 lowercase. Preferably, me URI does not include the 

tion and comparing the result. If it matches, die service ^ ^ ch ^ Mo$Xl ^ Preferably, it begins with a slash. For 

knows that someone who knows its pass-phrase--the c ^ for http v/wwwioo.com, the one-character string 

deity — replied, having verified that the user is who he 4 yw ^ usc £ 

claims to be. Now ^ authentication response is unique for each URL 

The service forwards Kusu and Au to the user 78. an( j calculable by the authenticated user, even without a 

The user extracts its copy of the session key from Kusu by 55 unique challenge. This risk associated with replay is not 

calculating the mask value and XORing. eliminated completely, but an attacker may replay only a 

The user verifies Au by computing it and comparing it to previously referenced URI during the window in which the 

the service response Rs. If it matches, the user knows service considers the session key to be valid. When reading 

that someone who knows his pass-phrase — the deity — Web pages, the only impact of replay is that the attacker may 

replied, having verified that the service is who it claims 60 re-read the page. Such a risk may be acceptable because die 

to be. attacker saw the page when it was captured it along with the 

Now the user and service are confident of each others' original request 

identities, and the two parties share a session key that they In the event the user is charged per page or if the request 

may use for encryption, if they so choose. "did** something, replays may be handled as follows. One 

Reauthentication 65 strategy to address the problem is to maintain some history. 

Reauthentication is a process by which a user and service. In its simplest form, the service sets a flag for this session 

having recently authenticated each other, may again mutu- when it does something for which replay is not acceptable. 
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If the user tries reauthentication cheating, and the flag is set, 
the service forces reauthentication. Because the cheating 
response is based on Cu and Cs, and those values change 
during reauthentication, the correct response for a given URI 
changes after reauthentication. Thus, reauthentication cre- 
ates a boundary after which previous requests may not be 
replayed 

Alternatively, the service may maintain a history of URIs 
far which replay may be inadequate. Using this scenario, 
reauthentication may be required only if the user tries 
reauthentication cheating on one of those URIs. 

Service-to-Deity Protocol 

The protocol used by the service and authentication deity 
in a preferred embodiment of the present invention may be 
summarized as follows. The service sends a request to the 
authentication deity and receives a reply. The requests and 
replies may be packaged in User Datagram Protocol (UDP) 
datagrams, or as byte streams over a Transport Control 
Protocol (TCP) connection. 

Finding the deity is a service configuration issue that may 
be resolved in several different ways. Preferably, the service 
knows the IP addresses, TCP or UDP port numbers, etc.. for 
the deities for a particular realm. Also, the service knows its 
name and pass-phrase in that realm. 

Object Formats 

In a preferred embodiment of the protocol of the present 
invention, every message is an object composed of other 
objects. Every object consists of a type-length-value 
encoded structure: 



Type 


Length MSB 


Length LSB 


Value octet 1 


Value octet 2 


Value octet 3 


Vahie octet 4 





Each box represents one octet Octets are transmitted in 
order from left to right, top to bottom. 
"Type" is a single octet that identifies the type of the 
object. 

"Length" indicates the number of octets following the 
length field, as a 16-bit, big-endian value. The appro- 
priate number of value octets — possibly none — follow 
the length field. Their meaning is determined by the 
type of the object; in some cases, the value octets 
contain a sequence of other objects. 

Here is an example of an object that contains 4 value 
octets: 



Type 


00000000 


00000 100 


Value octet 1 


Value octet 2 


Value octet 3 


Value octet 4 





Here is an example of an object that contains 1,000 value 
octets: 



Type 


0000001 1 


11101000 


Value octet 1 


Value octet 2 


Value octet 3 


Value octet 4 


Value octets 




Value octet 996 


Value octet 997 1 Value octet 998 1 Value octet 999 


Value 
octet 1000 





Preferably, no padding or alignment is used. If an object 
contains sub-objects, they follow one another with no pad- 
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ding. For example, an object whose value consists of three 
sub-objects may be represented as follows: 



5 



Object type 


00000000 


00001111 


Sub-obj 1 typo 


00000000 


0000O101 


Value octet 1 


Vahie octet 2 


Value octet 3 


Value octet 4 


Value octet 5 


Sub-obj 2 type 


00000000 


00000000 


Sub-obj 3 type 


00000000 


00000001 


Value octet 1 





In this example, there is a single object whose value 
j 5 contains 15 octets. In this example, the value is a sequence 
of three objects; the first of which contains five octets, the 
second of which is zero length* and third of which contains 
one octet. The meaning of each object depends on its type. 
The term "sub-object" may refer to an object when it is a 
2q part of another object but this is merely a matter of 
terminology. There is no difference in encoding nor in the 
meaning of the type field, regardless of whether the object 
is contained in some other object or not 
The Deity Information Field 
25 All messages may contain a field ("deity information 
field'*) that conveys information defined by a particular 
deity. The deity information field may be used in three 
contexts: 

In a request, a service may use the deity information field 
30 to tell the deity the nature of the action for which 
authentication is being performed, if there is some 
reason to do so. In addition, the service may ask the 
deity for particular information about the user name 
being authenticated, although, in general, the deity 
35 already knows what additional information to return to 
a particular service. 
In an affirmative response, the deity may return additional 

information about the user name. 
In other responses, the deity information field may indi- 
40 cate something about the nature of the problem. 

In general, different deities and services have different 
information appropriate for inclusion in the deity informa- 
tion field. It is difficult to conceive of a truly "standard** set 
of information to be included in the deity information field. 
45 Thus, the definition of the deity information field's contents 
is left to each deity. 
Message Object *types 

There are seven message object types, one for a request 
and six kinds of replies. 
50 Authentication request 

Authentication response, affirmative 
Authentication response, no service 
Authentication response, negative 
ss Authentication response, invalid service 
Authentication response, problem 
The various response flavors indicate various conditions 
of the account as described below. A message is an object 
that contains other objects. Preferably, the message itself is 
60 encoded as a type, length, and value, as described above, 
where the value consists of the concatenation of the com- 
ponent objects of that message. Each oomponent object 
consists of its own type, length, and value. Unless stated to 
the contrary, all messages contain exactly the objects indi- 
65 cated in the order shown. Optional components, such as the 
deity information field, may be omitted. 
Authentication Request 



05/26/2004, EAST Version: 1.4.1 



5,740,361 

13 14 

An authentication request contains the following sub- service for one reason or another. For example, she may be 
objects. a "free" user, but the service is provided only to paying 

accounts, or her billing choices may not include the service, 



Request identifier 



————— or Customer Service may be waiting for her to provide a new 
5 credit card number. The authentication deity's configuration 

Nr (Realm name) for this particular service determines the criteria applied by 

Nu 0^aa^ t) mc dcitv wnen making the decision to reply affirmative or no 

Cu (Challenge from user) Service. 
Cs (Challenge from service) 

Ru (Response from user) 10 ^mm— — ^ — ■ - - 

Deity Information (optional) p-m-st identifier 

Rs (Response from service) iwqrei wramw 



— ^ — — ————»«— - Canonical Nu (User name, case corrected) 

The request identifier contains arbitrary data that is not Ku^^ote^ed tSu^T* 

interpreted by the deity. It is echoed in a response to provide is Au (Authentication value for user) 

a way for the requesting service to match requests and Deity information Field (optional) 

responses. The deity information field contains additional As (Authentication value for service) 

information about the request and is described below. — — — — — — — — — 

Usually, it is omitted or null. (Le„ zero-length.) , ... . . * 

Rs is calculated as MD5(Ps+Z+M+Ps), where M is the 20 ^ object are identical to those for an 

request shown above, octet by octet from the type octet for affirmative response, but the service does not normally use 

the message object itself through the last length octet of the the keys or Au values. The deity information field may 

length field of the Rs object Thus, it serves to protect the include information useful in distinguishing the reason for 

entire request including its stricture length, etc toe D0 scrvicc response, if appropriate for this service. 

Authentication Response, Affirmative « 

An amrmative response indicates that the user name is Authentication Response, Negative 

recognized, and is indeed the user the service is talking to. a negative response means the user is not who she says 

she is. This response may result for several reasons. First 

— — ^— - there may be such a user name, but the service is not 

30 communicating with the actual user. Also, there may be such 

Canonical Nu (User name, case corrected) a user name but it is not an enabled account Alternatively. 

Kuss (Key obscured for service) . - , 

Kusu (KeV obscured far user) ^ te no such user namc ' 



Request identifier 



Deity Information Field (optional) 
^Authentication value for service) 



35 Request identifier 



KO>5(P^Z+N&4^Ni*Ku*^64CiHKu^M+ft) 
where M is the request shown above, octet by octet from the 45 



Preferably, the response contains the canonical user name Deity mfonnation Field (optional) 

in the desired case and is not the same object type as Nu in As (Authentication value for service) 

the request. In an environment that is not case sensitive, this — -— — — — — 
is the preferred form of the name, which may differ from the 

name in the request. The deity information field may contain 40 As is calculated as MD5(Ps+Z+M+Ps). The message may 

additional information about the user name. contain a deity information field if there is additional infor- 

As is calculated as: marion about the problem (e.g., for logging), but it may be 

omitted. 

Authentication Response. Invalid Service 

tyj* octet ^ last octet of An invalid request response means the request may not be 

the length field of the As object, inclusive. This serves to processed because the service is not what it claims to be as, 

protect the entire request Note that the Nu mentioned as the apparently, the service's pass-phrase is not known. The 

third component in the formula is the originally specified negative response may also be based on any other kind of 

user name, not the altered-case version in the response so authentication checking done by the deity, 
message. An amrmative response does not necessarily mean 

(hat it is reasonable to provide service to the user. Often. — _ — _ _ — 

there are criteria beyond a "y es " answer, that could mean Request identifier 

anything from "it's a valid user" to 'It's a valid user, but not Reid (optional) 

billable" to "it is an account that was signed up five minutes 55 — _ _ 

ago and we haven't had a chance to look at it yet" 

Typically, the authentication deity applies criteria appro- The deity information field, if present contains informa- 

priate to the requesting service. For example, if the service tion that allows the deity administrators to trace the problem, 

does not want to allow "free" users, the authentication deity That is no As field because there is no shared secret to 

may be configured to return a no-service response for such 60 authenticate the response, 

a user. Alternatively, the deity may be configured i to ^provide Authcntication Rcsponsc , 

an affirmative response, but include information in the oaty r 

information field that permits the service to distinguish A "problem" response indicates that the request may not 

"free" from "paying" users and treat them differently. be processed for some reason. There may be a failure in the 

Authentication Response, No Service 65 system, an unparsable request or a request for a realm that 

The no-service response is an indication that the user is is not handled by this deity. Other problems may also result 

whom she claims to be, but she is not entitled to access the in this response. 
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Request identifier 



Deity Information Field (optional) 
As (optional) 



The Deity Information Field may contain information that 
allows the deity administrators to trace the problem. As may 
or may not be present, depending on the nature of the 
problem (Le., whether there is a known shared secret with 
the server), if present, it is calculated as 

MDS(P*+Z+M+Ps) 

Object Types 

The following types of objects may be defined in this 
protocol. These object types apply to tie messages them- 
selves and objects contained in messages. These types do not 
apply to the contents of the deity information field. 

Authentication request — type 1 — The request to the 
authentication deity. Its contents consist of a sequence of 
other objects as described elsewhere. 
Authentication response, affirmative — type 2 
Authentication response, no service — type 3 
Authentication response, negative— type 4 
Authentication response, invalid service — type S 
Authentication response, problem — type 6 
Request identifier— type 128 — A request contains an 
identifier to assist in matching replies to requests. This 
identifier is opaque to the deity and is simply echoed in the 
reply so its value is defined only by the requesting entity. 
Preferably, the value is unique for each request, but it is 
otherwise meaningless. It may be of any length. 

Realm name— type 129— The name of the realm in which 
the user's and service's identities exist This value is 
included in the request to allow a deity to serve more than 
one realm. Preferably, the value consists of the name in 
Unicode, in big-endian order. There is no terminating null 
character, and the realm is generally treated as being case 
insensitive. For example, the realm aol.com may appear as 
follows: 



10000001 


oooooooo 


000011 10 


oooooooo 


01100001 


oooooooo 


ononu 


oooooooo 


01101 100 


oooooooo 


001011 to 


oooooooo 


OU00011 


oooooooo 


ononn 


oooooooo 


01101101 





10 



15 



20 



25 



30 



35 



40 



The type is 129, fourteen octets follow, and the big-endian 
Unicode representation of the seven characters "aol.com". 

Service name — type 130 — The name of the service in 
big-endian Unicode. 

User name — type 131— The name of the user in big- 
endian Unicode, (e.g.. gsb.) 

User challenge — type 132 — The user's challenge, a 
sequence of random octets. The length is not bounded by the 
protocol, but the deity may impose length restrictions, (e.g., 
a nunimum and maximum length.) All bit patterns arc 
permitted in the challenge. 

Service challenges — type 133 — The service's challenge, a 
sequence of random octets. The length is not bounded by the 
protocol, but the deity may impose length restrictions, (e.g., 
a minimum and mflTimnm length.) All bit patterns are 
permitted in the challenge. 
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User's response — type 135 — The user's response, con- 
taining 16 octets with the value specified above. This value 
is binary so any bit partem may be used. 

Service's response — type 136— The service's response, 
calculated as described above. This value is binary so any bit 
pattern may be used 

Key obscured for user— type 137— The key for the user, 
containing 16 octets as described in above. This value is 
binary so any bit pattern may be used- 
Key obscured for service — type 138— The key for the 
service, containing 16 octets as described above. This value 
is binary so any bit pattern may be used. 

AuthcDtication proof for user— type 139— The authenti- 
cation proof. Au. for the user, containing 16 octets as 
described above. This value is binary so any bit pattern may 
be used. 

Authentication proof for service — type 140— The authen- 
tication proof, As, for the service, containing 16 octets 
calculated as described above. This value is binary so any bit 
pattern may be used. 

Canonical user name — type 141 — The user name 
adjusted to canonical case, in big-endian Unicode. 

Deity Information Field — type 142 — Deity — specific 
request and response information. It may include a sequence 
of objects that contain information about the user's account, 
or indicate, by their presence or absence, some characteristic 
of the user's account The use of any particular object is a 
function of the deity's configuration for a particular service. 
Consider, for example, a "free" account in an environment 
where services are normally provided for a price. There are 
three most-likely possibilities for how the deity may handle 
a tree account when a particular service asks the deity to 
authenticate a user: 

If the account is free, return an affirmative response. 

If the account is free, return an affirmative response and 
include a ''free'' indicator in the deity information field. 

If the account is free, return a no-service response. 

The first alternative may be appropriate for a service that 
provides service to free users, when the service is not 
concerned whether the user is paying or not. The second 
alternative may be appropriate for a service that provides 
service to free users and handles free and paying users 
differently (e.g., provides a different class of service to free 
users man not-free users.) The third alternative may be 
appropriate for a service that does not provide service to free 
users. In that case, the deity may include a free indicator in 
the deity information field, to note the reason. 

Services may use the deity information field differently 
depending on the needs of the service. Therefore, the deity 
information field format preferably, is flexible to accom- 
modate the different ways in which services may use the 
field. A service-deity pair may define the deity information 
field in accordance with the type of information to be 
exchanged. Preferably, one type of sub-object that contains 
textual attribute/value pairs is defined to provide a standard 
encoding for one common need. 

Type 1 — Attribute/value pairs — If the deity information 
field contains a type-1 object, that object may be composed 
of a sequence of textual attribute/value pairs, where the 
value is optional. Sometimes, the presence or absence of an 
attribute is significant, with no need for a corresponding 
value. An attribute consists of a sequence of Unicode 
characters in the syntax attribute value] (i.c., the 
attribute name optionally followed by an character (code 
003 D) and a value.) All characters may be taken from the 
Unicode character set and stored in big-endian byte order. 
The attribute name may consist of any characters except a 
null or equal sign. The value may consist of any characters 
except a null. 
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WWW- Authenticate : 



Remote-Passphrase 

Realn^ M compusOT<coar, 

State^Imtbr, 

Realms^authen ©compuservo .com 

verify ® aol-conr iso-8859- 1 , lcmdS**, 
ChaUcngc="basc64 encoding of service cl 
50curity-Cotitext= M opaque M 



10 



20 



25 



HyperText Transfer Protocol Embodiment 
In one embodiment of the present invention, the mecha- 
nism of RPA is adapte d to work with the Hype r-Text 
Transfer Protocol (HTTP) of the WWW/Internet The HTTP 
client may indicate that it supports this authentication 5 
mechanism by whatever technique is appropriate. For 
example, when requesting access to a service, the client may 
include a header such as "Extension: Security/Remote- 
Pas sphrase" to indicate its ability to perform this authenti- 
cation mechanism. The extension mechanism is independent 
of the authentication mechanism. 

Next, a security context may be defined which represents 
a logical connection between a user (client) and Web server. 
Preferably, because the context spans HTTP connections, 
the server assigns a security context identifier— an opaque ^ 
string — when it creates a context The server assigns an 
identifier when it creates a context and it informs the client 
of its value in the Security-Context attribute of the WWW- 
Authenticate header. The client includes the identifier in the 
Authorization header of subsequent requests that refer to the 
same context 

From the client's point of view, the pair (server IP address, 
security context identifier) uniquely identifies a context The 
same is essentially true for the server, although a server may 
make its security context identifiers unique, rather than 
(client IP address, identifier) pairs. 

A client may refer to the same security context from 
different IP addresses, if he switches proxies. The client IP 
address alone may not be adequate to identify the security 
context. A multiple-user host, an HTTP proxy, and a SOCKS 
server are examples of situations in which the same IP 
address may be involved in many security contexts. Even an 
individual PC running two browsers falls into this 
category — if the user connects to a server from both 
browsers, two security contexts are established that may or 35 
may not refer to the same user identity. 

The security context "contains" information appropriate 
to the context, such as the realm name, user and service 
names, session key. challenges, state, etc Authentication 
schemes to be included in the headers may also be defined. ^ 
The client begins by making a request for which the server 
requires identification and authentication. If there is no 
Authorization header in the request the server requests 
authentication. All WWW- Authenticate and Authorization 
headers used with this scheme may include a Version 4$ 
attribute to identify the version of the protocol in use. When 
omitted, as in the examples below, Version="r may be 
implied, for this version of the protocol. 

Authentication 

The server creates a new security context assigns it an ^ 
identifier, and responds 401 Unauthorized and includes the 
header: 
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The first token specifies the authentication scheme. 
Remote-Passphrase. Following is a comma-separated list of 
attribute-value pairs. In HTTP, the first attribute is called 65 
"Realm" and specifies the realm in which the user, 
preferably, indicates his identity. However, RPA supports 



multiple realms so this is merely one realm acceptable to the 
server— perhaps its preferred realm. The State attribute may 
distinguish this as the initial request for authentication. 

The Realms attribute may provide a list of realms in the 
order preferred by the server, with the server's name in each 
realm. Each may be followed by a colon and a list of 
parameters separated by commas to drive the transformation 
from pass-phrase to 128-bit shared secret for that particular 
realm. The default transformation, if the colon and param- 
eters are omitted, is the Unicode character set in big-endian 
("network") byte order with all characters convened to 
lowercase and the MD5 hash algorithm. 

Preferably, a single parameter, "none**, is used to imply 
that the client already possesses a 128-bit value and no 
transformation from a textual pass-phrase is defined. 
Otherwise, three parameters may control the transformation 
from a textual pass-phrase to the 128-bit shared secret used 
by the authentication mechanism, if such a transformation 
takes place. The three parameters specify the character set 
Unicode 1.1 ("unicode-l-l") or ISO 8859-1 ("iso-8859-r); 
case conversion: convert to all caps (**uc w ), all lowercase 
("lc"), or as-is with no case conversion ("nc* 1 ); and hash 
function: MD5 ("md5 w ). Omitting the colon and parameters 
is equivalent to specifying "Unicode- 1-Uc,md5 rt . These 
parameters are part of the base authentication mechanism 
specification. Only the means of conveying them, an d the 
textual names shown above, are specific to this HTTP 
authentication scheme. Other variations may be added, but 
preferably, they are added to the base authentication mecha- 
nism. 

The Challenge attribute specifies the service's challenge. 
It is an arbitrarily long sequence of octets containing arbi- 
trary bit patterns, represented in base64. The client decodes 
it before using it in the authentication calculations. It may 
contain nulls or any other bit patterns. The client may 
decline to trust the server and abort at this point if it deems 
the challenge to be too short 

The Security-Context attribute contains the server- 
assigned security context identifier — an opaque string. The 
client creates its security context and repeats the request 
with an Authorization header: 



Authorization: 

Remote-Passphrase 

State^Initial", 

Security -Context=~opaque r \ 

User oame=-70003.12iy\ 

rha1W\ge="base64 importing of user challenge", 

RespODse^"base64 encoding of response" 



The first token specifies the authorization scheme. It is 
followed by the state, "Initial" for the initial authentication; 
the security context identifier, the realm chosen by the user, 
the user's identity in mat realm; the user's challenge; and the 
user's response. The service looks up the security context If 
the security context identifier refers to no context or refers 
to a context that is already established, the server creates a 
new security context with a new identifier, then responds 
401 Unauthorized and includes a fresh WWW- Authenticate 
header, as shown above, with which the client may repeat the 
request with correct authentication information. 

Any existing security context is unaffected. If the context 
identifier is recognized and that context is in the awaiting 
authentication state, the server performs the authentication 
process. The server may verify that the client's IP address 
matches that in the previous request that created the "pend- 
ing" context 
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If the authentication process fails, preferably, the server thentication. If it does not recognize the security context or 

refuses to process the request, but does not delete the if it recognizes the context but, the client's response is 

"pending" security context It generates a 401 Unauthorized incorrect the server requests authentication but does not 

response with a WWW-Authenticate header that indicates delete the existing security context In either of these cases, 

failure: s the server responds 401 Unauthorized and includes the 

appropriate WWW-Authenticate header. 

r Reauthentication 

www-Autheoticate: jf me server chooses to require reauthenti cation, it replies 

Remote-Passphnse 401 Unauthorized and includes the header: 



R*ato=*nonseoae", 10 
Slatc=TaUecT 



WWW-Autbenlkate: 



It is up to the client to try the request again (without an Ranote-Passpfara 
Authorization header), restarting the entire process, if it Realm=^mlm m use", 

believes that it was using the wrong pass-phrase but, it now 15 state =-Rcambcaticatc", 

has the right pass-phrase. Ch ^ c ^ W64 oi ^ 



Otherwise, having successfully authenticated the user, the 
server processes the client's request and returns an appro- The client retries the request with an Authorization field: 
priate response, including in its reply the following: 



20 



Authorization: 



WWW-Autbenticate; 



Remote-Passpfarase 



States* Rcaiitfaeoticatft" 



Reata=-ieatainuse*\ Security ^ontext^opaquc", 

Staie=-AutfaentkaV*r r 25 Challenge=-bwe64 encoding of uacr chalky, 

Session-Key="W64 encoding of session key", Rcsponse=^base64 encoding of response" 

Respon$e=**base64 encoding of response" ^ — '^'^ ^ 



If the response is correct — the user has proven his knowl- 

The "Authenticated" state indicates that the user was edge of the previously generated Kus for this context— the 

successfuUy authenticated, and includes the session key 30 server processes the request and includes in its reply: 
which is masked so only the user may extract it (Kusu), and 

the authentication deity's proof of the service* s identity (Au. — — — — — — — 

not Rs). The realm may be ignored, but preferably indicates www- Authenticate: 

the realm in which the identity was authenticated. Remote-Passpbrase 

Reauthentication Cheating 35 Reaim=* 4 icalm in uae", 

Reauthentication cheating is a further optimization for an state ^Reauthenticate", 

Rcsponse=i*n»se64 encoding of response" 



embodiment of the present invention compatible with Hi iy. 

In general, the HTTP protocol is quite unfriendly to 

challenge-response mechanisms. However, the reauthenti- The past-tense state indicates successful reauthentication 

cation cheating technique of the present invention may be 40 and includes the server's response. This response is of 
performed in parallel with an HTTP transaction. The "one- debatable relevance to HTTP given that the client's use of 
way" handshake of reauthentication cheating is preferable to reauthentication cheating implies its willingness to trust that 
the true reauthentication which is just as simple, but involves the server's identity has not changed 
two sequential requests because of the characteristics of If the client's response is incorrect, the server does not 

HTTP. 45 process the request However, there is a possibility that the 
In subsequent requests, the client tries to cheat by includ- client attempted to do reauthentication with an old security 
ing an Authorization header in its request: context identifier that has been reused by the server. 

Although the server preferably avoids reusing security con- 
— — — — — — . — — tcxt identifiers, it may attempt to avert the problem by 

Amhorizatkm: 50 forcing authentication by responding 401 Unauthorized and 

RemotesPassphrase including the header described above under Authentication, 

State="Ctaeating r *, 

Securuy-Q>ntext=-opaque", SUMMARY 
Response="base64 encoding of response" 



The need for secure communications is growing as the use 

„ . , . , of global computer networks increases. Users and services 

where the response is calculated ^ wait assurance^ that they axe communicating with the desired 

agreed-upon values plus the canonicalized method and URI ^ ^ flnd ^ fl need t0 leani md authcn . 

0f ^ . . *u - i- * n a ticate each other's identity. Consequently, there is a need for 

The HTTP specification suggests that clients be allowed authenticatioD j^duuism maTprovides a high level of 

to replay the previous ^^^f^^^^ t 60 Purity and is adaptable and flexible enoughTuse with 

an escape clausc-"for a period of tunc ^determined by the oWeat protocols used by communicating entities on 

authentication scheme"-so that ^ * * global computer networks. The authentication mechanism of 

declared to be zero. If the server is willing to accept the use ^ preWinvention meets these criteria and others includ- 

of reauthentication cheating, and the response is correct the . y 

server may process the request without comment. If it 65 lD ^V t , 

recognizes the security context but is not willing to cheat The service learns and authenticates the user s identity, 

(e.g.. it recognizes a replay) the server may demand reau- The user learns and authenticates the service's identity. 
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The mechanism is based on shared secrets: "pass-phrases" 
although they can be arbitrary bit patterns rather than 
text It relies on the knowledge of the user rather than 
the user's location, point of access, access device, etc. 

Neither the user nor the service nor eavesdroppers will 5 
learn the other's pass-phrase so neither the user nor the 
service will acquire the ability to impersonate the other. 

The mechanism derives a shared secret that may be used 
as a session key for subsequent authentication. 

The mechanism is easy to implement in clients and does 10 
not require the client to communicate with a third party 
(e.g., authentication deity). 

The mechanism may be incorporated into almost any 
protocol The mechanism is not designed around a 
protocol; the protocol is designed around the media- 15 
nisra It is suitable for incorporation into protocols such 
as HTTP. 

The mechanism provides the ability to accept an identity 
in any of a set of realms in which the user and service 
are members. Users may be authenticated in a familiar 20 
realm. They are not required to remember a separate 
pass phrase for every service nor are they required to 
use a different authentication mechanism for every 
service they want to access. 
The mechanism of the present invention works even if the 25 
service does not know the user's pass-phrase. In a 
distributed environment with many services that wish 
to authenticate the same set of users, it may be difficult 
and undesirable, to make users' pass-phrases available 
to all services. Therefore, the service does not know the 
user's pass-phrase and it does not learn the user's 
pass-phrase during the authentication process. 
The mechanism of the present invention may be used in 
the traditional case where the service knows the user's 
pass-phrase. There is no need to use a different mecha- 
nism in that case. 
Increasingly, businesses and other private and commercial 
entities wish to make their services and resources available 
to computer users throughout the world. In many instances, 
these entities would like to make their services and resources 
available through the WWW/Internet or other existing 
world-wide network so that they may be located easily and 
once located, may be accessed easily. However, users and 
services will be reluctant to communicate with one another 
unless each knows who or what is at the end of the 
connection. Remote Passphrase Authentication provides 
users and services with confidence regarding each other's 
identity that is needed to engage in on-line business and 
related transactions. 
What is claimed is; 
1. A method of authentication, said method comprising 
the steps of: 

(a) assigning a first identifier and a first pass-phrase to a 
first entity, said first identifier and said first pass-phrase 53 
associated with a realm; 

(b) assigning a second identifier and a second pass-phrase 
to a second entity, said second identifier and said 
second pass-phrase associated with said realm; 

(c) storing said first identifier, said first pass-phrase, said 
second identifier, and said second pass-phrase at an 
authentication entity; 

(d) requesting access to said second entity, said request 
initiated by said first entity and including said first 
identifier; 65 

(e) transmitting a first challenge from said second entity 
to said first entity; 
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(f) transmitting a second challenge from said first entity to 
said second entity; 

(g) calculating a first response involving said realm, first 
identifier, said first pass-phrase, said first challenge, 
said second identifier, and said second challenge, said 
first response calculated by said first entity; 

(h) calculating a second response involving said realm, 
said second identifier, said second pass-phrase, said 
second challenge, said first identifier, and said first 
challenge, said second response calculated by said 
second entity; 

(i) transmitting said first response to said second entity; 
(j) transmitting said realm, said first identifier, said first 

challenge, said first response, said second identifier, 
said second challenge, and said second response to said 
authentication entity; 

(k) verifying said first response, said verification involv- 
ing said realm, said first identifier, said first pass- 
phrase, said first challenge, said first response, said 
second identifier, and said second challenge, and said 
verification performed by said authentication entity; 

(1) verifying said second response, said verification 
involving said realm, said first identifier, said first 
challenge, said second identifier, said second pass- 
phrase, and said second challenge, and said verification 
performed by said authentication entity; 

(m) generating a first authentication proof for said first 
entity, said first authentication proof generated by said 
authentication entity and involving said realm, said first 
identifier, said first pass-phrase, said first challenge, 
said second identifier, and said second challenge; 

(n) generating a second authentication proof for said 
second entity, said second authentication proof gener- 
ated by said authentication entity and involving said 
realm, said first identifier, said first challenge, said 
second identifier, said second pass-phrase, and said 
second challenge; 

(o) transmitting said first authentication proof and said 
second authentication proof from said authentication 
entity to said second entity; and 

(p) verifying said second authentication proof, said veri- 
fication performed by said second entity; 

(q) transmitting said first authentication proof from said 
second entity to said first entity; and 

(r) verifying said first authentication proof, said verifica- 
tion performed by said first entity. 

2. The method of claim L wherein said first entity is a 
computer user and said second entity is an on-line service. 

3. The method of claim 2, wherein said on-line service is 
available via the World Wide Web. 

4. The method of claim 2. wherein communications with 
the on-line service are via the HyperText Transfer ProtocoL 

5. The method of claim 1. further comprising the steps of 
generating a session key for said first entity and said second 
entity, said session key generated by said authentication 
entity. 

6. The method of claim 5, wherein said first authentication 
proof and said second authentication proof includes said 
session key. 

7. The method of claim 1, further comprising the step of 
transmitting an authorization response for said first response 
from said authentication entity to said second entity. 

8. The method of claim 1. further comprising the step of 
transmitting an authorization response for said second 
response from said authentication entity to said second 
entity. 
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9. The method of claim 1. wherein said first response is 
calculated by application of the MD5 function to said first 
pass-phrase, said first identifier, said second identifier, said 
realm, said first challenge, and said second challenge. 

10. The method of claim 1, wherein said second response 
is calculated by application of the MD5 function to said 
second pass-phrase, said second identifier, said first 
identifier, said realm, said first challenge, and said second 
challenge. 

11. A method of authentication, said method comprising 
the steps of: 

(a) assigning a first identifier and a first pass-phrase to a 
first entity, said first identifier and said first pass-phrase 
associated with a realm; 

(b) assigning a second Identifier and a second pass-phrase 
to a second entity, said second identifier and said 
second pass-phrase associated with said realm; 

(c) storing said first identifier, said first pass-phrase, said 
second identifier, and said second pass-phrase at an 
authentication entity; 

(d) requesting access to said second entity, said access 
request initiated by said first entity and including said 
first identifier; 

(e) transmitting a first challenge from said second entity 
to said first entity; 

(f) transmitting a second challenge from said first entity to 
said second entity; 

(g) calculating a first response involving said realm, said 
first identifier, said first pass-phrase, said first 
challenge, said second identifier, and said second 
challenge, said first response calculated by said first 
entity; 

(h) calculating a second response involving said realm, 
said second identifier, said second pass-phrase, said 
second challenge, said first identifier, and said first 
challenge, said second response calculated by said 
second entity; 

(i) transmitting said first response to said second entity; ^ 
(j) transmitting said realm, said first identifier, said first 

challenge, said first response, said second identifier, 
said second challenge, and said second response to said 
authentication entity; 

(k) verifying said first response, said verification involv- 45 
ing said realm, said first identifier, said first pass- 
phrase, said first challenge, said first response, said 
second identifier, and said second challenge, and said 
verification performed by said authentication entity; 

(1) verifying said second response, said verification 5Q 
involving said realm, said first identifier, said first 
challenge, said second identifier, said second pass- 
phrase, and said second challenge, and said verification 
performed by said authentication entity; 

(m) generating a session key for said first entity and said 55 
second entity, said session key generated by said 
authentication entity; 

(n) obscuring said session key for said first entity, said 
obscuring involving said realm, said first identifier, said 
first pass-phrase, said first challenge, said second 60 
identifier, and said second challenge, and performed by 
said authentication entity; 

(o) obscuring said session key for said second entity, said 
obscuring involving said realm, said first identifier, said 
first challenge, said second identifier, said second pass- 
phrase, and said second challenge, and performed by 
said authentication entity; 
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(p) generating a first authentication proof for said first 
entity, said first authentication proof generated by said 
authentication entity and involving said realm, said first 
identifier, said first pass-phrase, said first challenge, 
said second identifier, said second challenge, and said 
obscured session key for said first entity; 

(q) generating a second authentication proof for said 
second entity, said second authentication proof gener- 
ated by said authentication entity and involving said 
realm, said first identifier, said first challenge, said 
second identifier, said second pass-phrase, said second 
challenge, and said obscured session key for said 
second entity; 

(r) transmitting said first authentication proof and said 
second authentication proof from said authentication 
entity to said second entity; and 

(s) verifying said second authentication proof, said veri- 
fication performed by said second entity; 

(t) transmitting said first authentication proof from said 
second entity to said first entity; and 

(u) verifying said first authentication proof, said verifica- 
tion performed by said first entity. 

IX The method of claim 11, further comprising the steps 

of: 

(a) transmitting a third challenge from said second entity 
to said first entity; 

(b) transmitting a fourth challenge from said first entity to 
said second entity; 

(c) calculating a third response involving said realm, said 
first session key, said first identifier, and said second 
identifier, said response calculated by said first entity; 

(d) transmitting said third response from said first entity 
to said second entity; 

(e) verifying said third response; said verification per- 
formed by said second entity; 

(f) calculating a fourth response involving said realm, said 
second session key. said first identifier, and said second 
identifier, said fourth response calculated by said sec- 
ond entity; 

(g) transmitting said fourth response from said second 
entity to said first entity; 

(h) verifying said fourth response, said verification per- 
formed by said first entity. 

13. The method of claim 12, further comprising the step 
of repeating steps (a)-(h), 

14. The method of claim 11, wherein said access request 
is a HyperText Transfer Protocol request 

15. The method of claim 14, wherein said HyperText 
Transfer Protocol request includes an authorization header 
with a response involving said first session key. said realm, 
said first identifier, said second identifier, said first 
challenge, said second challenge, and a Uniform Resource 
Identifier. 

16. A system for authentication comprising: 
a first entity; 

a second entity; 

an authentication entity; 

a first identifier and a first pass-phrase for said first entity, 
said first identifier and said first pass-phrase associated 
with a realm; 

a second identifier and a second pass-phrase for said 
second entity, said second identifier and said second 
pass-phrase associated with said realm; 

means for said authentication entity to retrieve according 
to said realm said first identifier, said first pass-phrase, 
said second identifier, and said second pass-phrase; 
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means for said second entity to transmit a first challenge 
to said first entity; 

means for said first entity to transmit a second challenge 
to said second entity; 

means for said first entity to calculate a first response 5 
involving said realm, said first identifier, said first 
pass-phrase, said first challenge, said second identifier, 
and said second challenge; 

means for said second entity to calcite a second response J0 
involving said realm, said second identifier, said second 
pass-phrase, said second challenge, said first identifier, 
and said first challenge; 

means for transmitting said realm; said first identifier, said 
first challenge* said first response, said second ^ 
identifier, said second challenge, and said second 
response to said authentication entity; 

means for said authentication entity to verify said first 
response, said verification involving said realms said 
first identifier, said first challenge, said second 20 
identifier, and said second challenge; 

means for said authentication entity to verify said second 
response, said verification involving said realms said 
first identifier, said first challenge, said first response, 
said second identifier, and said second challenge; 25 

means for said authentication entity to generate a first 
authentication proof for said first entity; 

means for said authentication entity to generate a second 
authentication proof for said second entity; ^ 

means for transmitting said first and said second authen- 
tication proofs from said authentication entity to said 
second entity; 

means for said second entity to verify said second authen- 
tication proof; 35 

means for transmitting said first authentication proof from 
said second entity to said first entity; and 

means for said first entity to verify said first authentication 

F«)f. 4, 

17. The system of claim 16. wherein said first entity is a 
computer user and said second entity is an on-line service. 

18. The system of claim 16, wherein said first response is 
calculated by application of the MD5 function to said first 
pass-phrase, said first identifier, said second identifier, said 
realm, said first challenge, and said second challenge. 45 

19. The system of claim 16, wherein said second response 
is calculated by application of the MDS function to said 
second pass-phrase, said second identifier, said first 
identifier, said realm, said first challenge, and said second 
challenge. 

20. A system for authentication comprising: 

a realm identifier associated with a first identifier and a 
first pass-phrase for a first entity; 
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a second identifier and a second pass-phrase for a second 
entity, said second identifier and said second pass- 
phrase associated with said realm; 

means for authenticating said first entity, said means 
including said realm identifier; and 

means for authenticating said second entity, said means 
including said realm identifier. 

21. The system of claim 20 wherein said first entity 
authentication means and said second entity authentication 
means includes authentication proofs for said first entity and 
said second entity, said authentication proofs including said 
realm identifier. 

22. A method of authentication for use with Hyper-Text 
Transfer ProtocoL said method comprising the steps of: 

transmitting a connection request from a client to a server, 
creating a server security context and assigning an iden- 
tifier to said server security context, said server security 
context created by and said identifier assigned by said 
server in response to said connection request from said 
client; 

transmitting a first authentication header from said server 
to said client, said first authorization header comprising 
a realm list, a status indicator, a service challenge, and 
said service security context; 

creating a client security context and assigning said 
identifier to said client security context said client 
security context created by said client; 

transmitting an authorization header from said client to 
said server, said authorization header comprising a 
status indicator, said client security context, a realm 
selected from said realm list, a client identifier in said 
selected realm, a client challenge, and a client response 
to said service challenge; 

examining said client security context to determine an 
authentication state for said client security context, said 
examination performed by said server, and 

performing authentication if said client context identifier 
is recognized by said server, said authentication per- 
formed by said server. 

23. The method of claim 22 further comprising the step of 
transmitting from said server to said client a second authen- 
tication header including a status indicator indicating said 
client was successfully authenticated and a session key. 

24. The method of claim 22 wherein said server security 
context identifier and said client security context identifiers 
are opaque strings. 

25. The method of claim 22 wherein said server security 
context comprises a realm name, a server identifier, a session 
key, a server challenge, and a status indicator. 

26. The method of claim 22 wherein said client security 
context comprises a realm, a client identifier, a session key. 
a client challenge, and a status indicator. 
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